<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Replication FAQ</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="rep.html" title="Chapter 13.  Berkeley DB Replication" />
    <link rel="prev" href="rep_partition.html" title="Network partitions" />
    <link rel="next" href="rep_ex.html" title="Ex_rep: a replication example" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 12.1.6.2</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Replication FAQ</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="rep_partition.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 13.  Berkeley DB Replication </th>
          <td width="20%" align="right"> <a accesskey="n" href="rep_ex.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="rep_faq"></a>Replication FAQ</h2>
          </div>
        </div>
      </div>
      <div class="orderedlist">
        <ol type="1">
          <li>
            <p>
                <span class="bold"><strong>Does Berkeley DB provide support
                    for forwarding write queries from clients to
                    masters?</strong></span>
            </p>
            <p> 
                Yes, for applications with simple data and transaction 
                models, Berkeley DB provides automatic write forwarding 
                as a configurable option. Use of this option enables some
                write operations to be performed on a client environment.
            </p>
            <p>
                In cases where a more complex data and transaction model
                is used, this protocol is left entirely to the
                application. In addition, an application can use 
                Replication Manager message channels to send its own messages
                to other sites in the replication group using Replication
                Manager's internal communications infrastructure.
                See
                <a class="xref" href="rep_ex_chan.html" title="Ex_rep_chan: a Replication Manager channel example">Ex_rep_chan: a Replication Manager channel example</a> for information
                about a sample program that demonstrates this use of
                message channels). For a Base API application, it is
                possible to use the communications channels it
                establishes for replication support to forward
                database update messages to the master, since Berkeley
                DB does not require those channels to be used
                exclusively for replication messages.
            </p>
          </li>
          <li>
            <p>
                <span class="bold"><strong>Can I use replication to
                partition my environment across multiple
                sites?</strong></span>
            </p>
            <p> 
                Yes, you can create partial views to accomplish
                this. See <a class="xref" href="rep_partview.html" title="Replication views">Replication views</a> for more
                information. 
            </p>
          </li>
          <li>
            <p>
                <span class="bold"><strong>I'm running with replication but
                I don't see my databases on the client.</strong></span>
            </p>
            <p> 
                This problem may be the result of the application
                using absolute path names for its databases, and the
                pathnames are not valid on the client system. 
            </p>
          </li>
          <li>
            <p>
                <span class="bold"><strong>How can I distinguish Berkeley
                DB messages from application messages?</strong></span>
            </p>
            <p>
                Replication Manager provides its own communications
                infrastructure for replication messages. You can
                create message channels to pass application-specific
                messages using this infrastructure (see <a class="xref" href="comm_repsites.html#repmgr_channels" title="Using Replication Manager message channels">Using Replication Manager message channels</a> for more
                information).
            </p>
            <p> 
                In a Base API application, there is no way to
                distinguish Berkeley DB messages from
                application-specific messages, nor does Berkeley DB
                offer any way to wrap application messages inside of
                Berkeley DB messages. Distributed applications
                exchanging their own messages should either enclose
                Berkeley DB messages in their own wrappers, or use
                separate network connections to send and receive
                Berkeley DB messages. The one exception to this rule
                is connection information for new sites; Berkeley DB
                offers a simple method for sites joining replication
                groups to send connection information to the other
                database environments in the group (see <a class="xref" href="rep_newsite.html" title="Connecting to a new site">Connecting to a new site</a> for more information). 
            </p>
          </li>
          <li>
            <p>
                <span class="bold"><strong>How should I build my <span class="bold"><strong>send</strong></span>
                function?</strong></span>
            </p>
            <p> 
                This depends on the specifics of the application.
                One common way is to write the <span class="bold"><strong>rec</strong></span>
                and <span class="bold"><strong>control</strong></span> arguments' sizes and data to a
                socket connected to each remote site. On a fast, local
                area net, the simplest method is likely to be to
                construct broadcast messages. Each Berkeley DB message
                would be encapsulated inside an application specific
                message, with header information specifying the
                intended recipient(s) for the message. This will
                likely require a global numbering scheme, however, as
                the Berkeley DB library has to be able to send
                specific log records to clients apart from the general
                broadcast of new log records intended for all members
                of a replication group.
            </p>
          </li>
          <li>
            <p>
                <span class="bold"><strong>Does every one of my threads of
                control on the master have to set up its own
                connection to every client? And, does every one of
                my threads of control on the client have to set up
                its own connection to every master?</strong></span>
            </p>
            <p> 
                This is not always necessary. In the Berkeley DB
                replication model, any thread of control which
                modifies a database in the master environment must be
                prepared to send a message to the client environments,
                and any thread of control which delivers a message to
                a client environment must be prepared to send a
                message to the master. There are many ways in which
                these requirements can be satisfied.
            </p>
            <p> 
                The simplest case is probably a single,
                multithreaded process running on the master and
                clients. The process running on the master would
                require a single write connection to each client and a
                single read connection from each client. A process
                running on each client would require a single read
                connection from the master and a single write
                connection to the master. Threads running in these
                processes on the master and clients would use the same
                network connections to pass messages back and forth.
            </p>
            <p> 
                A common complication is when there are multiple
                processes running on the master and clients. A
                straight-forward solution is to increase the numbers
                of connections on the master — each process
                running on the master has its own write connection to
                each client. However, this requires only one
                additional connection for each possible client in the
                master process. The master environment still requires
                only a single read connection from each client (this
                can be done by allocating a separate thread of control
                which does nothing other than receive client messages
                and forward them into the database). Similarly, each
                client still only requires a single thread of control
                that receives master messages and forwards them into
                the database, and which also takes database messages
                and forwards them back to the master. This model
                requires the networking infrastructure support
                many-to-one writers-to-readers, of course.
            </p>
            <p>
                If the number of network connections is a problem
                in the multiprocess model, and inter-process
                communication on the system is inexpensive enough, an
                alternative is have a single process which
                communicates between the master and each client, and
                whenever a process' <span class="bold"><strong>send</strong></span> 
                function is called, the process
                passes the message to the communications process which
                is responsible for forwarding the message to the
                appropriate client. Alternatively, a broadcast
                mechanism will simplify the entire networking
                infrastructure, as processes will likely no longer
                have to maintain their own specific network
                connections. 
            </p>
          </li>
        </ol>
      </div>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="rep_partition.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="rep.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="rep_ex.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Network partitions </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Ex_rep: a replication example</td>
        </tr>
      </table>
    </div>
  </body>
</html>
